22 | P a g e
BestPurchase app class model inspiration). Attributes and methods within each entity have
been expanded to demonstrate the hierarchy of communication that occurs between the
interface and the package elements. For an example of how the app calls upon these methods
to fulfill a request, see the Appendix B BestPurchase Sequence Diagram).
Packages
The BestPurchase App is a mobile device interface meant to be used by many people in several
different ways for viewing information about a grocery store’s inventory and potentially making
a purchase (See Appendix A for use cases and functional requirements considered for the
BestPurchase app). It is worth mentioning that beyond sufficiency, flexibility and reusability,
this app needs to consider design goals that reflect large-scale, simultaneous use (efficiency),
sensitive data communication (security) and acceptable uptime as necessitated by eCommerce
(reliability). The packages identified section 5.1 are evaluated using these primary design goals
below. The GUI package needs little explanation and is omitted from the breakdown.
• Package name: Inventory
• Design goals for this package: The primary design goals of this package are sufficiency and
reusability.
• Design tradeoffs for this package: Sufficiency is a measure of how well a module handles
the given requirements, while reusability demonstrates how components of a module can
be recycled and used in other parts (Dennis, 2021). From the use cases and functional
requirements outlined in Appendix A, the BestPurchase app interface needs to interact with
products available for purchase that are members of several different lists, including what is
in the selected store inventory, within the store’s promotional ad, and from the shopper’s
purchase history. This goal of sufficiency is met within the inventory package. Next, the
StoreInventory, StorePromotion and CustomerHistory entities are subclasses of the
ProductList superclass. As mentioned above, each one of these entities is essentially a list
of products with different focus. As a result, the product data structure and several
methods can be generalized into a superclass and reused as the foundation of the
subclasses, making the implementation less redundant.
Cohesion is high within the Inventory package as all entities involve products or lists of
products. No attributes from within any of the entities pertain directly to any entity outside
of the package without cause. Coupling within the package is high, as all entities are linked
with either an aggregation or generalization association. Coupling outside of the package is
moderate, with the external associations being of the dependency from the GUI interface,
aggregations to the Store and PaidAccount entities, and a composition to the Store entity.
Although efficiency is sacrificed to maintain these associations, they are necessary as the
Store instance dictates the specific StoreInventory and StorePromotion, and the Customer
instance by way of the PaidAccount entity determines the unique CustomerHistory. An
alternative would be to collapse attributes and methods from the StoreInventory and